home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5526 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.4 KB  |  122 lines
  1. Newsgroups: comp.lang.c++
  2. Path: netcom.com!marnold
  3. From: marnold@netcom.com (Matt Arnold)
  4. Subject: Re: pInt = new int [987654321L], what will ha
  5. Message-ID: <marnoldDMA3n0.GqG@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. References: <Pine.SOL.3.91.960203215559.25805E-100000@hamlet.uncg.edu> <31146e4c.197257088@nntp.ix.netcom.com> <Pine.SOL.3.91.960204100529.12786A-100000@hamlet.uncg.edu>
  8. Date: Mon, 5 Feb 1996 01:18:36 GMT
  9. Sender: marnold@netcom13.netcom.com
  10.  
  11. "QIAN . ZHONG" <q_zhong@hamlet.uncg.edu> writes:
  12.  
  13. > 
  14.  
  15. >On Sun, 4 Feb 1996, Mike Rubenstein wrote:
  16.  
  17. >> "QIAN . ZHONG" <q_zhong@hamlet.uncg.edu> wrote:
  18. >> 
  19. >> > 
  20. >> > Hi, folks:
  21. >> > 
  22. >> > Here is a question about new, the following is my code:
  23. >> > 
  24. >> > int main(void)
  25. >> > {
  26. >> >     int *pInt;
  27. >> >     long Block = 987654321L;
  28. >> > 
  29. >> >     pInt = new int[Block];
  30. >> >     if(pInt == NULL) dosomething();
  31. >> > }
  32. >> > 
  33. >> > My problem is when I compile the program for DOS under large memory 
  34. >> > model, above new nerve return NULL, I guess compiler convert
  35. >> > 
  36. >> > new int[987654321L] --- convert --> new int[ ACONST]
  37. >> > where ACONST = 0xffff , or ACONST = 0x7fff, am I right ?
  38. >> > Is this a DOS thing ? or a C++ thing ? Is this portable ?
  39. >> 
  40. >> More likely the system just doesn't have 987 meg free memory, so it
  41. >> can't do the allocation.  Newer compilers will throw an exception, but
  42. >> older ones simply return the null pointer.
  43. >> 
  44. >Hi, Michael:
  45.  
  46. >Thanks for your message, my real problem is the compiler will not return a
  47. >null pointer, even if I set_new_handler(0);
  48.  
  49. >I am confused. Please help me again. I use BC++ 4.0.
  50.  
  51. Your problem is related to compiling for DOS.  Most compilers use make
  52. size_t equivalent to a int.  DOS comilers usually make ints 16-bit
  53. quantities and longs 32-bit quantities.
  54.  
  55. Since new is prototyped as follows...
  56.  
  57.    void* operator new(size_t size);
  58.  
  59. ...it follows that you can only allocate chunks of memory whose size can
  60. be expressed with 16-bits using a DOS C++ compiler.
  61.  
  62. So, when you write...
  63.  
  64.    new int[BIG_NUMBER];
  65.  
  66. ...where BIG_NUMBER is a value which cannot be expressed in 16-bits and
  67. passed to new as a size_t (a 16-bit int, remember?), the compiler will
  68. perform an implicit conversion for you (often with an accompanying 
  69. warning).  In fact, compiling your sample code above, Borland C++ 4.52
  70. issues the following warning...
  71.  
  72. Warning CRAP.CPP 10: Conversion may lose significant digits in function main()
  73.  
  74. This warning means that the 32-bits required to represent 987654321 are
  75. being truncated to 16.  New will be passed 26801 (that's 897654321 with it's
  76. top 16 bits missing).  This is a perfectly reasonable value for the 
  77. tyipcally 16-bit memory management routines included with DOS compilers
  78. to allocate.  Thus, your code above will probably always succeed.  You're
  79. only asking new for 27K or so.
  80.  
  81. If you wish to allocate blocks of memory larger than 64K (16-bits allows you
  82. to express numbers up to 65535, or 64K, right?), in a DOS environment, most 
  83. DOS compilers will let you use "huge" pointers, along with accomanying "huge"
  84. memory allocations, in which 32-bit numbers can be used.
  85.  
  86. For example, your sample program can be modified to do what you really
  87. wanted it to do under borland C++ 4.52...
  88.  
  89. int main(void)
  90. {
  91.  int huge* pInt;
  92.  long Block = 8000000L;  // see below
  93.  
  94.  pInt = new huge int[Block];
  95.  if(pInt == 0)
  96.     dosomething();
  97.  
  98.  return 0;
  99. }
  100.  
  101. I changed the block size to about 8 megabytes instead of over 987 megabytes,
  102. which was a bit unreasonable.  Now, this program works properly.  However,
  103. it now uses the non-standard keyword "huge" (common to most DOS compilers,
  104. tho).
  105.  
  106. And, it was working properly before, except you didn't understand what was
  107. happening to your 32-bit 987654321 block size when passed to a 16-bit new.
  108.  
  109. Had you heeded the compiler warning (I do hope you have all warnings 
  110. enabled), you probably could have tracked down this problem yourself 
  111. instead of posting it to the world.
  112.  
  113.  
  114. Regards,
  115. -------------------------------------------------------------------------
  116. Matt Arnold                       |        | ||| | |||| |  | | || ||
  117. marnold@netcom.com                |        | ||| | |||| |  | | || ||
  118. Boston, MA                        |      0 | ||| | |||| |  | | || ||
  119. 617.389.7384 (h) 617.576.2760 (w) |        | ||| | |||| |  | | || ||
  120. C++, MIDI, Win32/95 developer     |        | ||| 4 3 1   0 8 3 || ||
  121. -------------------------------------------------------------------------
  122.